Middleware & WXS to PLC Interface

Middleware & WXS to PLC Interface

Posted by Robert Ward | 10/18/2020

Updated by Robert Ward | 5/30/2021; 7/1/2022; 5/12/2023; 2/29/2024

On projects that interface with either Pendant Middleware or Revolution St. WXS, those communications from the PLC to the Software are initiated from the PLC.

Pendant uses a cyclic polling method such that the Middleware or WXS will poll a Trigger bit on a regular basis. The actual frequency of this can change on a case by case basis, but is generally between 100-500ms.

Therefore, Pendant will poll a trigger bit, e.g. Middleware.TxTrigger, and when set TRUE by the PLC, the software will read the TxMessage STRING (or UDT) and perform a lookup.

Once complete, Pendant will set the Middleware.TxTrigger bit to FALSE letting the PLC user know new data has been read and logged.

Another WXS Middleware will process the request and when results are available, check the RxTrigger. If FALSE, the WXS will write the new results into RxMessage, write the RxTriggerID, and then set RxTrigger to TRUE. The PLC will monitor the rising edge of RxTrigger and when active, read the RxTriggerID and result data to update the data array in the PLC. Once the data is read, the PLC will set RxTrigger to FALSE to allow the WXS to transact the next message.

There is also a Heartbeat Watchdog. This provides the PLC with the ability to detect that comms have been lost between the Middleware/WXS and alter the logic accordingly. The typical update time for the Heartbeat tag is every 2-seconds.

General use is, the PLC user will create a tag with Data Type [udtMiddleware] or whatever the user has called the UDT. Therefore, as some examples:

  • A comms point to perform Host Lookup for a scanned barcode on the Outbound Scanner:

    • Tag Name: OutboundScanComm

    • Data Type: udtMiddleware

    • Example Elements:

      • OutboundScanComm.CommName
      • OutboundScanComm.Heartbeat
      • OutboundScanComm.TxTrigger
      • OutboundScanComm.TxMessage

  • A comms point to send actual sort information to the WXS:

    • Tag Name: OutboundScanVerify

    • Data Type: udtMiddleware

    • Example Elements:

      • OutboundScanVerify.TxTrigger
      • OutboundScanVerify.TxTriggerID
      • OutboundScanVerify.TxMessage

Further detail can be found below in the Explanation of Tags and photos:

Explanation of Tags:

  • TxHeartbeat:

    • Data Type: BOOL
    • Use: The Middleware/WXS will toggle this bit between TRUE and FALSE at a regular interval, usually between 500ms and 2s. If this bit should remain TRUE or FALSE for longer than the predetermined amount of time, the PLC should set the TxLossOfComms tag TRUE

  • RxHeartbeat:

    • Data Type: BOOL
    • Use: The Middleware/WXS will toggle this bit between TRUE and FALSE at a regular interval, usually between 500ms and 2s. If this bit should remain TRUE or FALSE for longer than the predetermined amount of time, the PLC should set the RxLossOfComms tag TRUE

  • TxWatchdogTRUE

    • Data Type: TIMER
    • Use: This is the tag used for the TRUE watchdog timer as seen below in the example photo.

  • TxWatchdogFALSE

    • Data Type: TIMER
    • Use: This is the tag used for the FALSE watchdog timer as seen below in the example photo

  • RxWatchdogTRUE

    • Data Type: TIMER
    • Use: This is the tag used for the TRUE watchdog timer as seen below in the example photo.

  • RxWatchdogFALSE

    • Data Type: TIMER
    • Use: This is the tag used for the FALSE watchdog timer as seen below in the example photo

  • TxLossOfComms:

    • Data Type: BOOL
    • Use: The PLC user will set this bit TRUE when either the TRUE or FALSE timers’ .DN bit is TRUE. This bit will reset when the Heartbeat begins to toggle again.

  • RxLossOfComms:

    • Data Type: BOOL
    • Use: The PLC user will set this bit TRUE when either the TRUE or FALSE timers’ .DN bit is TRUE. This bit will reset when the Heartbeat begins to toggle again.

  • LossOfDatabaseCnx:

    • Data Type: BOOL
    • Use: The Middleware/WXS monitors the connection to the database. If it is detected that the database connection is lost, the Middleware/WXS will set this bit TRUE in the PLC

  • MiddlewareError

    • Data Type: BOOL
    • Use: This tag captures all internal related Middleware Errors that would prevent the Middleware from satisfying its transactional requirements to the PLC. While the Heartbeat might still be active, this tag is often used to pause induct until Middleware Errors are resolved.

  • RxQueryResponseTime

    • Data Type: INT
    • Use: Not used at this time.

  • HostLookupTime

    • Data Type: DINT
    • Use: This is the PLC Round Trip time, in milli-seconds, as measured from the time the TxTrigger bit is set True until the time that the WXS/Middleware sets the RxTrigger bit true. That is to say, the time from when the PLC requests a lane assignment until when it receives that assignment.

  • RxErrorID

    • Data Type: INT
    • Use: Not used at this time

  • RxError Message

    • Data Type: STRING
    • Use: Not used at this time

  • TxTrigger:

    • Data Type: BOOL
    • Use: The PLC user will set this bit TRUE when they are initiating a request to the Middleware/WXS, after new data has been written into TxMessage. Once the Middleware/WXS has performed the lookup and written results into RxMessage and RxTriggerID, the Middleware/WXS will set this bit to FALSE.

  • RxTrigger:

    • Data Type: BOOL

    • Use: [Only used in bilateral comms] If the Middleware/WXS wishes to initiate comms to the PLC, this bit will be set TRUE after new data has been written into RxMessage and RxTriggerID. Bilateral comms might be used in an instance where the PLC can send more data quicker than the Middleware/WXS can respond.

      • E.g. say a scanner is inducting packages every 500ms and transmitting messages every 500ms. If the lookup took more than 500ms, say 1000ms, then the Middleware/WXS would need to respond to messages based on TxTriggerID. That way the PLC user can match RxTriggerID to a past TxTriggerID that has come and gone and might be located downstream on the conveyor

  • TxTriggerID

    • Data Type: INT
    • Use: This shall be a unique Scan ID between 1-512

  • RxTriggerID

    • Data Type: INT
    • Use: This shall be a corresponding Result ID between 1-512

  • TxMessage:

    • Data Type: UDT

    • Use: This is the location of the message text the PLC user wishes to serve up to the Middleware/WXS. Use the following TxMessage UDT for this:

      • .Code

        • Data Type: STRING
        • Use: generally the barcode of the package scanned or the ID of the item data is requested for

      • .Weight:

        • Data Type: REAL
        • Use: Measured weight

      • .LaneAssigned:

        • Data Type: INT
        • Use: if Divert Confirmation, this is the lane the WXS advise the package to sort to

      • .LaneActual:

        • Data Type: INT
        • Use: if Divert Confirmation, this is the lane the container was actually sorted to

      • .Height:

        • Data Type: REAL
        • Use: Measured Height

      • .Length:

        • Data Type: REAL
        • Use: Measured Length

      • .Width:

        • Data Type: REAL
        • Use: Measured Width

      • .CodeQuality

        • Data Type: INT
        • Use: This is the metric from the scanner relating to the quality of the barcode read - shall come to middleware in a value of 0-100

      • .DecodeTime

        • Data Type: INT
        • Use: Decode Time, in milliseconds, from the Scanner

      • .Reason:

        • Data Type: INT

        • Use: the Reason Code associated with a Divert Confirmation:

      • UserField1:

        • Data Type: STRING
        • Use: Custom User Data Field 1

      • UserField2:

        • Data Type: STRING
        • Use: Custom User Data Field 2

      • UserField3:

        • Data Type: STRING
        • Use: Custom User Data Field 3

      • UserField4:

        • Data Type: STRING
        • Use: Custom User Data Field 4

This KB Article has accompanying downloads. Please reach out to your rep to retrieve those.